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Abstract- With April 1st, 2012 the implementation of Directive 2006/24/EC on the retention of data ^agrated or 
processed in connection with the provision of publicly available electronic communications service*, or^fpuDlic 
communications networks came into effect in Austria. With this implementation, not only the ohtiaflion^of the providers 
of telecommunications services are controlled with respect to the retention of communications dra^xM also the powers of 
the security and law enforcement authorities with respect to request both retention data as wall a^jlnditional connection 
data (e.g., security police in the course of fulfilment of affairs). To make the retrieval of suchfiMA as transparent as 
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possible, legally secure and traceable, all requests (with only few exceptions) must be carra«pffonly via the so-called 
DLS, a central exchange service. This allows preventing unauthorized or hidden inquiries tactically and not just legally. 
Both requests and replies must be transmitted only over HTTPS connections to Jl^/Thi a\id must further be secured 
using end-2-end encryption, enforcing a blind central service. ^^^^^^^ 

I. Introduction 

In her book on publicity rights, Gillian Black proposes that JjAyaSy is the desire of an individual to be free of 
intrusion [1]. The European Convention on Human Right&lteirab, "that everyone has the right to respect for his 
private and family life, his home and his correspondence^^Siis right may be restricted to a person of public interest 
or for the purpose of prosecution, though this might na^to be seen very controversial [2]. 

Austria was faced exactly with this probjaHL^ter the course of the implementation of the European Data 
Retention Directive. Here two controversia/suwBcts have to be dealt with at the same time. First, the infringements 
of the right of every Austrian citizen 9k nrs privacy by the data collection itself, as well as a safe handling during 
processing and especially transfer ^W^ich data between authorities and providers. The aim pursued was accordingly 

i citizens. 

The approach the authoild^igned and partly implemented for Austria, deliberately does not use the handover 
interface defined by EK^fhd tries to prevent the concerns that largely rely on the judgment of the German Federal 
Constitutional C^^8< as well as various other considerations [4] [5] [6] . 

II. State of the Art for Privacy in Governments IT-Infrastructures 



processing and especially transler^uich data between authorities and providers, the aim pursued was accor 
to install a system that conf^^^^me requirements of the directive and to protect the privacy of Austrian citi2 
e authgiydp 

Vrak^^r?*/. [7] states, "that it has been proved that privacy concerns are a main antecedent of trust in e- 
ver\ient systems intention of use. Therefore, information systems that are not privacy aware are not trusted and 




thusllbt accepted by citizens". They argue that conventional ways for preventing attacks on the data's' privacy by 
mainly employing Privacy Enhancing Technologies (PETs) must involve an organizational context for selecting the 
appropriate technical, organizational and procedural countermeasures for building privacy aware systems. 



1 http://human-rights-convention.org/ 

2 http://www.etsi.org/ 
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A short overview of privacy in the context of digital government is given by Vaidya [8], by examining potential 
concerns and causes of privacy breaches. This work was based on existing laws regarding privacy, as well as some 
of the technological solutions and potential challenges. It therefore stresses the importance and responsibility of 
preventing data misuse coming along with the increase in data being collected, stored, and analyzed. 

Haryadi and Malik [9] give recommendations for governments on how to setup a Data Retention System in his 
paper. It describes points of recommendation to National Telecommunication Regulatory Bodies in establishing data 
retention regulations and deals with fundamental questions, as e.g., functionalities, logging and site of^sfltragte. 
Moreover, it takes into account the matter of data exchange by taking the example of the European Telecom 
Standards Institute (ETSI) handover interface. 



III. Governmental Data Retention 

♦ 




Government triggered data retention in common has the objective of surveillance, as tmeyWe'specially their law 
enforcement, realized the importance of communication data concerning the fighL^^^t crime and terrorism. 
Therefore, a growing number of countries enacted legal backgrounds for the intercep^pri of communication data in 
case of serious suspicions. In addition, e.g., the European Union (EU) enfrft^^^he Directive on the retention of 
data generated or processed in connection with the provision of puh^^VaVailable electronic communication 
services or of public communications networks (2006/24/EC)", know^^^tlte Data Retention Directive (DRD) [10]. 



According to this Directive, every EU member state must retainV>e<$ific communication parameters of their users 
for the period of six months up to two years for the purpose ofCrafcnvestigation, detection and prosecution of serious 
crime. This paper will later on refer especially to this dire^h^. 

A. Data Retention Principles of the European Data Retention Directive 

In their paper, Haryadi and Malik [9] pn^e^ recommendations to establish data retention regulations for 
countries. When it comes to technical aaptct^ they state that the most advanced technical guidelines in Lawful 
Interception (LI) Data Retention islhe CTiUOTtion of ETSI technical specifications and technical reports 3 . Presumably 
most of the member states implemrnt«| the DRD according to these specifications. 

One of the standards. thXfcfeblTS 102 657. deals with the aspect on how to handover retention data from a 
provider to an authoritjyfcVjJes a reference model showing a principle setup. This reference model is depicted in 
Fig. 1 . An entitled arffltolily requests data from a communications provider using a defined handover interface. As 
the figure shows#^l^sceiving Authority in some cases might not be the same as the Issuing Authority. The Issuing 
Authority s^^K request to an Administrative function in the provider's data retention system. According to the 
request^l^*ovider fetches the data from its database using the Data Store Management Function and transmits it 
t^heVermed Receiving Authority. The provider internally feeds his Data Storage from different sources, as e.g., 
emanflnternet access, Internet telephony, mobile telephony, fixed network telephony and so on, using a Data 
Collection Function. The standard also defines a Log Functionality for event logging of the activities in the Data 
Retention system. 



3 http://www.etsi.org/standards 
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Figure 1. Data Retention System Reference Model 



alfta^K) guarantee 

their confidentiality, integrity, unlawful access and alteration as well as accidental loss. ]\4g1^>ve^it clarifies that 



B. Regulations by the Directive to Guarantee Retained Data 's Privacy and Security 

Concerning processed retention data's privacy and security the directive enacts several regul 




the regulations of the Data Privacy Directive (DPD, 95/46/EC) and of the Directive orLPiwacy and Electronic 
Communications (DPEC, 2002/58/EC) are furthermore applicable as far as no spjgrfi? regulations are stated. 
Basically, from a data security point of view, retention data are to be treated aqd prWtected equally to operational 
data processed in the provider's system providing the corresponding CGimH^uipation service, as far as specific 
regulations do not require the implementation of stricter measurement/ri^pursuant to this the provider has to 
implement organizational and technical measurements and procedur^^Jat only authorized staff are able to access 
retention data and that retention data are deleted after their comujjlsofy period of storage. Moreover, each Member 
State is engaged to designate one or more national supervis^jJ^lWfchorities, which is responsible for monitoring and 
ensuring an appropriate level of data security [10]. 




C. Reservations Concerning the ETSI Handover Integ 

As part of the implementation of the DRD!^jri\Lustria some concerns about the ETSI standard for a handover 
interface have been raised. Due to date rfd^^on reasons, access via a direct interface to the database systems of 
providers was a controversial subjact, sin^it may potentiate the infringement of European privacy law. The concept 
of the ETSI interface allows a SQrM|lla5t grid investigation within all covered communications data of the DRD. This 
circumstance corresponds tSkjC*8 of data mining. The associated possibilities of linking data goes far beyond the 
competence of the DRD^5v*= re f° re was seen as a not acceptable method [11]. 

In addition, th£ fvoVtlonary history of the ETSI standards and the contribution of experts from different 
intelligence or^ffNj^kions give enough reasons for certain suspicion concerning the underlying background 
intentions 4 . ♦A 

^^Vl IV. The Austrian DLS - A Central Exchange Service for Retention Data 
TforJpe data exchange the directive states that, "Member States shall adopt measures to ensure that data retained in 
accordance with this Directive are provided only to the competent national authorities in specific cases and in 
accordance with national law" [12]. By following this and due to the aspects mentioned in chapter III-C, we 
developed a construct not following the ETSI standards for Austria. Amendments in the Austrian 
Telecommunications Act regulate exactly which data may be requested by authorities under what conditions. An 



4 https://moechel.com/lectures/ 
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associated technical Data Security Decree gives a holistic legal as well as technical solution for the mandatory 
system to exchange this data between authorities and provider, on the basis of official request letters (in PDF format) 
and defined response files (in CSV format) [13]. The fundamental challenge was to develop this system with 
appropriate level of privacy while allowing secure communication and data transfer between providers and entitled 
authorities. In addition, the superior requirements of the DRD had to be met. 



Authorities (1,n) 




Figure 2. The Principle Concept of the Central Exchange System (DL 
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DLS), allowing data transmission only between provider and authorities, 
framework builds on a central exchange service, embedded as a servio 
(short PV). Access to this service is made possible only by one portaj^^l 
enables a transparent, legally as well as technical, secure data i 
event for requesting data. ^^^^ 

As already mentioned, the DLS represents a kind ofrrBb for information on communication and retention data. To 
ensure data security and privacy, data shoul^^^^be exchanged in a confidential way. Therefore, the DLS is 
designed in a way that the content transri^fedV requests and responses cannot be inspected by the DLS, even with 
the content not being accessible to sySem^administrators. The system as a whole can only be compromised if a 
client itself is compromised and ^eXdesign should not provide possibilities to intercept information, neither by 
active MitM attacks, nor b eavesdropper. This requires strong cryptographic measures with encryption of 

both, the request and thej^jjo/Re, already in the infrastructure of each actor, and consequently before being sent to 
the DLS. Additionall^mWata transmission between clients must be secured at the transport level. 

The transmisai^^> secured with a transport encryption based on HTTP Secure (HTTPS), using proven 
technologieiVnSjrcing HTTPS/TLS 5 1.2. As stated in the corresponding RFC 5246, "the protocol allows 
ciient/sa**^5kpplications to communicate in a way that is designed to prevent eavesdropping, tampering, or message 

Awntionally to the transport encryption, the actual content of a request and the corresponding answers must be 
encrypted as well. For this, a hybrid encryption method based on a Public Key Infrastructure with symmetric session 
keys is used. Therefore, it is achieved that the data can be decrypted only by the dedicated receiver. This also 
ensures the appropriation of the data to its objectives according to the Directive. Thus, the demand of the blindness 
of the DLS for the exchanged data is fulfilled. 



5 http://tools.ietf.org/html/rfc5246 



30 th - 31 st July, 2014, University of Greenwich, London, UK. 
DOI: 10.978.819252/12219 



Page I 58 



Proc. of the Int. Conf. on eBusiness, eCommerce, eManagement, eLearning and eGovernance (IC5E 2014) 

The public and private key are specified to use RSA-2048 bits for client certificates, and RSA-4096 bits for the 
Root certificate, while the used symmetric session key has to follow the specifications of AES-256 in CBC mode, 
using PKCS5 padding (also known as Standard Block Padding). This is conforming to the recommendations of the 
BSI 6 for secure key material [14]. 

B. The Rollout-Concept of the DLS 

The DLS presents its users specialized clients in form of a web application, depending if they are an author^ or 



provider. The clients are implemented based on HTML and Java Script in order to run entirely in a web tt^^er, 
while including all designated use-cases and functionalities stipulated to authenticate, set and get requ^J^ encrypt 
and decrypt data, digital sign data and check digital signatures, as well as to provide required statistid^^hese clients 
satisfy all legislative as well as technical requirements of the Data Security Decree (DSI& TMfce clients must 
authenticate using the corresponding Access Portal to logon on to the DLS. VJ^ 

The unusual approach to perform all cryptography in the browser instead of using j software also revealed 

the need to generate the symmetric AES key inside the browser. At the time of feplementation, there was no 
possibility to utilize a key generator or random number generator provickd^Cjy operating system. Therefore, a 
concept for the creation of the required symmetric session keys insid^flW orowser was required. In order to 
accomplish this for the web application provided by the DLS, differ^^ources for filling entropy pools had to be 
used. The mentioned sources gather information which are colle^nfcl i+i entropy pools, which will be utilized by the 
Fortuna pseudo-random number generation algorithm [15] jda^NVped by Neils Ferguson and Bruce Schneier [16]. 
By using this cryptographic secure pseudo number gener^o^ symmetric AES-key will be generated [16]. This key 
will then be used for data encryption according to the"^^ryption concept. 

C. Challenges Coming Along with the DLS <C\ 

The main issue by taking this approach* iLtly t it relies on implementing a system to generate the CSV-response 
files by the data providers, which ^revel^them from buying or using already in place software, e.g. according to 
the ETSI standards. v/j* 

Furthermore, the client-sSej^^ is provided to the participants by the DLS. This effectively means the DLS must 
be completely trusted. JtwjjMlS could selectively send down java script with encryption functionality completely 
disabled, or the DLSj^fc|wrprovide the wrong public keys. While the client is audited, the public keys are certified, 
and a website ej^^^ith certificate fingerprints, it takes expertise to ascertain given and used certificates, as well as 
the client. Tjb^^fere, we advise to additionally use methods to ensure the integrity of the client and the certificates, 
as presaffl^^ Popa et al. [17]. 

1 VI. Conclusion 

The Austrian legislator obviously has managed to implement the directive under conditions as little invasive as 
possible in respect of data privacy and legal protection aspects, by introducing technical, organizational and 
procedural countermeasures. For the implemented encryption scheme the data sovereignty stays with the 
communicating partners, as third-parties capturing the encrypted data are not able to have insight to any content. By 



6 https://www.bsi.bund.de/ 

30 th - 31 st July, 2014, University of Greenwich, London, UK. 
DOI: 10.978.819252/12219 



Page I 59 



Proc. of the Int. Conf. on eBusiness, eCommerce, eManagement, eLearning and eGovernance (IC5E 2014) 



using strong cryptography, coping government satisfying authentication and security regulations, all 
communications are subject to certain general principles. For all Internet connections, a transport encryption is in 
any case provided. In addition, inquiries from authorities and the answers by providers must be encrypted (content 
encryption). Requests and responses can only be received and decrypted and thus viewed individually by each 
designated recipient. The DLS (or its administrators) cannot have insight to exchanged data and therefore confirm 
the blind concept, as the encryption and signing of data is done prior to the submission to the DLS. The Provider 
shall ensure that it provides the necessary data by business case. The DLS itself cannot take substantivt^(^rVl 
function here. The log data do not require data encryption. However, they are transferred to the DLS j» me^hs of 
transport encryption. The DLS can read log data and store it accordingly in its database. The sys|ffl^*ra whole 
practically prevents setting unauthorized inquiries, by establishing transparency on the data ^xcmbged and proves 
accountability of taken actions. Although, the European Court of Justice declared the Ds^Xetention Directive 
invalid, we believe that the DLS system will be able to easily adapt to upcoming lega^fKhpolitical changes. The 
concept of the DLS has been time-proven with similar systems emerging 7 8 , and can^^ty be customized to be used 
for any sensitive data exchange between government authorities, as welL^m\ economy. Future improvement 



should focus on implementing facilitative integrity controls and advancedN^^graphy in order to enhance the level 
of security and performance. 
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